Have you ever received a field error like "String length specified does not match the supported length" and wondered which of the many fields caused the issue? Me too, this PR changes all that :-)

My proposal makes the element name available in the IntuitRequestException for programatic access to the element name associated with the error message. It also adds the element name if present (it's optional) to the exception message so that messages are prepended with the specific field if present.

Tradeoffs: Adding the element name to the exception message could break existing code if logic was based on the EXACT message returned. Logic based on an exact match instead of an includes would be brittle to message changes from QBO and it's a bad practice to have logic based on error text (especially external party error text). I think it's a good tradeoff to add the element name to the message which is generally used everywhere and by default error messages will now indicate which element they apply to. The message already concatenates the underlying error message and error detail fields and this seemed like very useful context to add to the message by default.